test: Deflake adaptive statistics and browser plugin tests on slow CI runners - #2203
Merged
Merged
Conversation
vdusek
marked this pull request as ready for review
August 31, 2026 08:19
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #2203 +/- ##
==========================================
- Coverage 93.73% 93.73% -0.01%
==========================================
Files 181 181
Lines 12825 12852 +27
==========================================
+ Hits 12022 12047 +25
- Misses 803 805 +2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Pijukatel
approved these changes
Sep 4, 2026
vdusek
added a commit
that referenced
this pull request
Sep 8, 2026
…2221) Two adaptive crawler tests flake on the Windows CI shard for the same reason. This supersedes #2207, which fixed one of them from a base that predates #2203. The browser sub crawler navigates under `PlaywrightCrawler`'s own `navigation_timeout`, a 60s `SharedTimeout` shared by the pre/post-navigation hooks and `goto`. That budget is separate from `request_handler_timeout`, because `BasicCrawler` applies the handler timeout only around the router call. So a cold Chromium launch on a saturated runner can blow the navigation budget while the handler timeout still has minutes left, and relaxing the handler timeout does nothing about it. - `test_adaptive_crawling_statistics` fails with `assert 3 == 1` ([example run](https://github.com/apify/crawlee-python/actions/runs/34120120329/job/101736011265)). When navigation exceeds the 60s budget, `BasicCrawler` retries the whole request, which is correct behavior, and every adaptive counter increments again. The failing run timed out twice before succeeding: 60 + 60 + 17s matches its 146s crawler runtime. It now passes a 5 minute `navigation_timeout`, the same ceiling #2203 already gave its handler. - `test_adaptive_playwright_crawler_timeout_in_sub_crawler` fails with `Expected 'browser_handler' to be called once. Called 0 times.` ([example run](https://github.com/apify/crawlee-python/actions/runs/33467016711/job/99728873095)). It sets `max_request_retries=0`, so one slow navigation fails the only attempt before the handler ever runs. It now passes a 120s `navigation_timeout`, matching the handler timeout it already relaxes. Both keep their existing assertions, so a real double-counting or missed-increment regression still fails them. Passing the key needs `navigation_timeout` in `_PlaywrightCrawlerAdditionalOptions`; `PlaywrightCrawler.__init__` already accepts it and `ty` reports `invalid-key` without it. Verified with deterministic fault injection in both cases. For the statistics test, monkeypatching `Page.goto` to stall the first two navigations by 70s reproduces the exact `assert 3 == 1` with two retries under the 60s ceiling, and passes in 71s under the 5 minute one with all counters at 1; plus 0 failures in 39 runs of that test alone and 31/31 for the whole file serially. For the sub crawler timeout test, a playwright-only pre-navigation delay of 70s consumes the shared budget and reproduces the CI failure under the default ceiling, passing under 120s, with 0/96 failures across 8 concurrent Chromium-saturated lanes afterwards. The adaptive module passes under `-n auto` in 6 of 7 runs; the exception hit an unrelated `Errno 98` in the uvicorn test server fixture, caused by running several pytest processes at once locally. *✍️ Drafted by Claude Code*
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two unit tests flake on the Windows CI shard under parallel load (example run):
test_adaptive_crawling_statisticsasserts each adaptive counter equals exactly 1, but when a slow Chromium launch pushes the browser sub-crawl past the default 60srequest_handler_timeout,BasicCrawlerretries the request - correct behavior - and every counter increments again (assert 2 == 1). The test now passes a 5-minuterequest_handler_timeout, removing the retry trigger while keeping the exact-count assertions, so a real double-counting regression still fails it.test_new_browserranpage.gotowith Playwright's default 30s timeout, which the first navigation on a saturated runner can exceed. Raised to 60s, matchingtest_browser_pool.py.Verified with deterministic fault injection: a 70s stall in
BrowserPool.new_pagereproduced the exact CI failure before the fix and 0/3 failures after; a 40s-slow server reproduced thegototimeout with the default and passed with 60s. Plus 0/30 failures re-running both modules underpytest -n auto. No production code is touched.✍️ Drafted by Claude Code